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Reference list 

The following are the references for this section: 

• Software Input/Output: Administration (553-3001-311) 

• Data Networking Guidelines (553-3023-103) 


Overview 


This chapter provides guidelines and recommendations to help plan, 
engineer, and test the Voice Gateway Media Card and Internet Telephone 
network on the Meridian 1 system. 

For Succession Communication Server for Enterprise (CSE) 1000 Release 
2.0 systems, also refer to Data Networking Guidelines (553-3023-103). 

The following procedures are contained within this chapter: 

• Procedure 1, “Performing the Network assessment procedure” on 
page 138 

• Procedure 2, “Calculating TLAN traffic” on page 156 

• Procedure 3, “Calculating WAN traffic” on page 161 

• Procedure 4, “Assessing link utilization” on page 167 
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See “Configuration of the DHCP Server’’ on page 211, for engineering 
guidelines to set up and configure the Dynamic Host Configuration Protocol 
(DHCP) server to support the Voice Gateway Media Card and Internet 
Telephones. 

IP address requirements 

This section describes the IP address requirements for each node, for each 
card, and for each Internet Telephone. 

A node is a group of ITG-P Line Cards and Succession Media Cards within a 
given Meridian 1 or Succession CSE 1000 system. Each card within a node 
has two IP addresses: a node for the Telephony LAN (TLAN) and a node for 
the Meridian 1 or Succession CSE 1000 Embedded LAN (ELAN). Each node 
has one Node IP address on the TLAN, that is dynamically assigned to the 
connection server on the node Master. The Internet Telephone uses the Node 
IP address during the registration process. 

All ELAN addresses for all nodes must be on one subnet. All ELAN 
addresses must be on the same subnet as the Meridian 1 or Succession 
CSE 1000 Core ELAN. All TLAN addresses must be in the same subnet for 
a given node. 

General Requirements for a Node’s IP Addressing 

The following is a list of IP addresses that must be assigned to configure a 
node: 

• IP address for every TLAN interface of every Voice Gateway Media 
Card 

• IP address for every ELAN interface of every Voice Gateway Media 
Card 

• Voice LAN (TLAN) Node IP address (This address is shared among all 
the cards.) This alias IP address appears dynamically on the TLAN port 
of one card in the node, the Leader or node Master. 

• On the Succession CSE 1000 Rel 2.0 system, an IP address for the 
Signaling Server ELAN and Signaling Server TLAN 
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In addition to the IP addresses that must be assigned, additional network 
information must be entered: 

• Management LAN (ELAN) gateway IP address 

• Management LAN (ELAN) subnet mask 

• Voice LAN (TLAN) subnet mask 

• VLAN gateway IP address 



CAUTION 

You must use separate subnets with the Voice Gateway 
Media Card for ELAN and TLAN. 


The default setting of separate ELAN and TLAN subnets offers the following 
benefits: 

• Separate subnets are easier to configure for traffic management and 
Quality of Service (QoS). 

• Separate subnets protect the Meridian 1 and Succession CSE 1000 
ELAN from general LAN traffic, including broadcast and multicast 
storms 

• Separate subnets are more secure against unauthorized access 
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Voice Gateway Media Card IP address requirements 

The IP address information for each card is set in the Configuration tab of 
the ITG Node Properties window of the IP Telephony Gateway - IP Phones 
application. The IP address requirements for each card depend on the node 
subnet option. 

You must provide an IP address for an ELAN and TLAN port. On the ELAN, 
all cards must be on the same subnet, which is the same subnet that the 
Meridian 1 and Succession CSE 1000 is connected to. On the TLAN, all 
cards in a node must be on the same subnet. 


The ELAN address corresponds to the Management MAC address which is 
assigned during manufacturing and cannot be changed. Locate the faceplate 
sticker on the Voice Gateway Media Card. The ELAN/Management MAC 
address is the MOTHERBOARD Ethernet address. 


Separate subnet Voice Gateway Media Card IP address 
requirements 


You must use separate subnets for the IP Telephony node. Each Voice 
Gateway Media Card requires a: 
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IP network assessment procedure 

An efficient IP Line network design begins with an understanding of traffic 
and the underlying network that carries the traffic. To determine the network 
requirements of the specific system, the technician must perform the steps in 
Procedure I. 

Procedure 1 

Performing the Network assessment procedure 

1 Estimate the amount of traffic processed by the Meridian 1 or Succession 
CSE 1000 system through the IP Line network. See “Calculate IP Line 
traffic requirements” on page 155. 

2 Assess if the existing corporate intranet can adequately support voice 
services. See “Calculate IP Line traffic requirements” on page 155 and 
“Assess WAN link resources” on page 161. 

3 Organize the IP Line network into “zones” representing different 
topographical areas of the network that are separated according to 
bandwidth considerations. See “VoIP bandwidth management zones” on 
page 164. 

4 Set a variety of service parameters to improve service and coordinate 
(with the IP administrator) the prioritization of voice packets with data 
traffic. See “Set service parameters” on page 171. 

5 Provide the necessary IP network infrastructure: 

a. lOBaseT or 100BaseTX Ethernet connection. 

b. IP address. Each Voice Gateway Media Card requires lOBaseT 
ELAN or 10/IOOBaseT TLAN unicast IP address. 

c. One additional IP address for each node. The node IP address is the 
TLAN for a subnet. 


End of Procedure 
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After completing the network assessments, the technician can design and 
implement the IP Line network. This can involve modifications to both the IP 
Line elements and to the existing network. Post-installation network 
measurements (see page 191) must be made on a regular basis to make sure 
QoS standards are maintained. Figure 6 shows an example of the TLAN and 
ELAN topology. 

Figure 6 

TLAN and ELAN Topology 
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Codecs 


The Internet Telephones and Voice Gateway Media Cards support different 
codecs and codec parameters with different compression rates and audio 
quality. The Meridian 1 and Succession CSE 1000 selects the appropriate 
codecs based on user-configurable parameters. For instance, an Internet 
Teiephone-to-Internet Telephone within a LAN can be set up using G.711 at 
64 Kbps. For an Internet Telephone-to-Internet Telephone call over a WAN, 
the call can be set up using G.729A or G.729AB at 8 Kbps. These data rates 
and the Voice Gateway Channel Server on the Voice Gateway Media Card 
are for the voice stream only. Packet overhead is not included. 

The Terminal Proxy Server (TPS) and the Voice Gateway Channel Server on 
the Voice Gateway Media Card have a predefined table of codec option sets 
that can be supported. The first entry in the table has the highest quality audio 
(BQ = Best Quality) and requires the largest bandwidth. The last entry 
requires the least bandwidth (BB = Best Bandwidth) with lower voice 
quality. 

When the Call Server sets up a Call Server connection between an Internet 
Telephone-to-Internet Telephone or Internet Telephone-to-Voice Gateway 
Channel Server, the predefined table determines which codec it selects for 
that connection. This information is provided to the Meridian 1 and 
Succession CSE 1000 as part of the Internet Telephone registration sequence. 
For more information about the registration sequence, refer to “Configuration 
of the DHCP Server" on page 211. The Meridian I and Succession CSE 1000 
use this information to set up a speech path to select a codec that both 
endpoints support. As part of zone management, it further selects the codec 
based on whether it is trying to optimize quality (BQ) or bandwidth (BB). 


CAUTION 

/§\ When voice compression codecs are used, voice quality 
/ I \ is impaired if end-to-end calls include multiple 
compressions. 
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Codec refers to the voice coding and compression algorithm used by the 
DSPs on the Voice Gateway Media Card. Different codecs provide different 
levels of voice quality and compression properties. The specific codecs and 
the order in which they are used are configured in the TPS, and Meridian 1 
and Succession CSE 1000. 

Table 32 shows which codecs are supported on the Meridian 1 and 
Succession CSE Rel 1.1 systems, and on the Succession CSE 1000 Rel 2.0 
systems: 


Table 32 

Supported codecs 


Codec 

Supported on Meridian 1 and 
Succession CSE 1000 Rel 1.1 

Supported on Succession 
CSE 1000 Rel 2.0 


G.711 

Yes 

Yes 


G.729A 

Yes 

Yes 


G.729AB 

Yes 

Yes 


G.723.1 

No 

Yes 


T.38 

No 

Yes 

— 

G.711 Clear Channel 

No 

Yes 

Note 1: The G.723.1 codec is supported only on Succession CSE 1000 Release 2.0 system. 
The supported G.723.1 codec has bit rates of 5.3 Kbps and 6.3 Kbps. The user can configure 
the G.723.1 codec with a 5.3 Kbps bit rate; however, the system accepts both G.723.1 5.3Kbps 
and 6.4Kbps from the far end. 

Note 2: The T.38 and G.711 Clear Channel codecs are supported for fax calls and are only 
supported on the Succession CSE 1000 Release 2.0 system. T.38 is the preferred codec type 
for fax calls over virtual trunks. However, the G.711 Clear Channel codec is used if the far end 
does not support the T.38 codec. 
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Table 33 lists the payload sizes for the different codecs: 

Table 33 

Codec payload sizes 


Codec Payload 

G.711 

10ms, 20ms, 30ms 

G.729A 

10ms, 20ms, 30ms, 40ms, 50ms 

G.729AB 

10ms, 20ms, 30ms, 40ms, 50ms 

G.723.1 

30ms 

T.38 

supported for fax calls 

G.711 Clear Channel 

supported for fax calls 


Note: If there are multiple nodes on a system and the same codec is 
selected on more than one node, ensure that each node has the same voice 
payload size configured for the codec. 

Codec configuration 

Configure codec in the DSP Profile sections of OTM and Element 
Management. 

Meridian 1 and Succession CSE 1000 Rel 1.1 

Figure 7 on page 143 shows the list of codecs available on the DSP Profile 
tab within OTM’s ITG Line 3.0 application. The Codec Options sub-tab 
presents a table of different sets of codec options identified by a codec setting 
index number. There is a list of up to 32 codec settings for G.711, G.729A, 
and G.729AB. The lesser codec setting index corresponds to BQ (Best 
Quality) in LD 117 zone configuration. The greater codec setting index 
corresponds to BB (Best Bandwidth). For more information, see“Codec 
selection” on page 191. 
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Figure 7 

Codec list on OTM 2.0 
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For codec configuration in the Meridian I and Succession CSE 1000 Rel I. I 
systems, see “Configuring DSP profile data” on page 284. 
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Succession CSE 1000 Rel 2.0 

Figure 8 on page 144 shows the list of codec types that are displayed in the 
Element Management. 


Figure 8 

Codec list in Element Management 


>Codec G711 

^Codec G729ft 

>Codec G729AB 

> Codec G723.1 

> Codec G711 CLEAR CHANNEL 



> Codec T38 FAX 




lect M 


The G.711, G.711 Clear Channel, and T.38 Fax codecs are automatically 
selected and cannot be unselected. Even though these codecs cannot be 
unselected, the payload size, and the jitter buffer for G.711 can be changed. 
For G.711 Clear Channel, only the jitter buffer can be changed. 

The user can select all three, any two, any one, or none of the G.729A, 
G.729AB, and G.723.1 codecs. If the G.729A or G.729AB codec is selected, 
the user can change the payload size and the jitter buffer. If the G.723.1 codec 
is selected, the user can change only the jitter buffer, because the only 
supported payload size is 30 msec. 

For codec configuration in the Succession CSE 1000 Rel 2.0 system, see 
“Configuring DSP Profile data” on page 346. 
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Codec Registration on Succession CSE 1000 Rel 2.0 

After the configuration of codecs is complete, the Internet Telephones and 
DSPs have to register the configured codecs with the Call Server. 

Codec registration for Internet Telephones 

The Internet Telephones register both the G.711 a-law and mu-law codecs, 
and any codec(s) configured by the user. The codecs that can be configured 
by the user are G.729A, G.729AB, and G.723.1. 

Note: Internet Telephones do not register the fax codecs (T.38 and 
G.71 I Clear Channel). 

The minimum number of codecs registered for an Internet Telephone is two: 
G.711 a-law and G.711 mu-law (G.71 i is always configured). 

The maximum number of codecs registered for an Internet Telephone is five: 
G.71 I a-law, G.711 mu-law, G729A, G729AB, and G.723.1. 

Example 1 

A user configures a G.711 mu-law codec (with a 30 msec payload) and a 
G.723.1 codec (with a 30 msec payload). 

The following three codecs arc actually registered: 

1 G.711 mu-law (30 msec) 

2 G.71 I a-law (30 msec) 

3 G.723.1 (30 msec) 

Example 2 

A user configures four codecs: 

1 G.711 a-law codec with a 10 msec payload 

2 G.729A codec with 50 msec payload 

3 G.729AB codec with 30 msec payload 

4 G.723.1 codec with a 30 msec payload 
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The following five codecs are actually registered: 

1 G.7I I a-law (10 msec) 

2 G.711 mu-law (10 msec) 

3 G.729A (50 msec) 

4 G.729AB (30 msec) 

5 G.723.1 (30 msec) 

Codec registration for DSPs 

DSPs register the following codecs: 

• both G.711 a-law and G.711 mu-law codecs 

• both fax codecs (T.38 and G.711 Clear Channel) 

• one best bandwidth (BB) codec if at least one of G.729A, G.729AB. or 
G.723.1 codecs was configured by the user. The best bandwidth (BB) 
codec is based on the codec type. The order of preference for choosing 
the best bandwidth codec is G.729AB. G.729A, and then G.723.1. 

The minimum number of codecs registered for DSPs is four: G.711 a-law, 
G.711 mu-law, T.38 and G.711 Clear Channel. 

The maximum number of codecs registered for DSPs is five: G.711 a-law, 
G.711 mu-law, T.38 and G.711 Clear Channel and one of G.729AB. G.729A. 
or G.723.1. 

Example 1 

A user configures four codecs: 

1 G.711 a-law codec with a 10 msec payload 

2 G.729A codec with 50 msec payload 

3 G.729AB codec with 30 msec payload 

4 G.723.1 codec with a 30 msec payload 


553-3001-204 Standard 4.00 November 2002 




IP Network Engineering Guidelines Page 147 of 724 


The following five codecs are actually registered: 

1 G.711 a-law (10 msec) 

2 G.711 mu-law (10 msec) 

3 G.729AB (30 msec) 

4 T.38 

5 G.711 Clear Channel 

The G.729AB codec is selected, as it is the first in the order of preference of 
the “best bandwidth” codecs. The G.729A and G.723.1 codecs do not get 
registered. 

Example 2 

A user configures three codecs: 

1 G.711 mu-law codec with a 20 msec payload 

2 G.729A codec with 30 msec payload 

3 G.723.1 codec with a 30 msec payload 

The following five codecs are actually registered: 

1 G.711 mu-law (20 msec) 

2 G.711 a-law (20 msec) 

3 G.729A (30 msec) 

4 T.38 

5 G.71 I Clear Channel 

The G.729A codec is selected, as it precedes the G.723.1 codec in the order 
of preference of the “best bandwidth” codecs 

Codec negotiation for Succession CSE 1000 Rel 2.0 

For every virtual trunk call, a common codec must be selected for the call. 
This is known as codec negotiation. Codec negotiation for virtual trunk calls 
is performed through the H.323 FastStart and Terminal Capability Set (TCS) 
messages. 
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For a call setup with the FastStart procedure, the originating node sends its 
codec list in the FastStart element in the SETUP message to the terminating 
node. For a call setup using the SlowStart procedure or for a call modification 
(media redirection), each node sends its codec list in the TCS message to the 
other node. 

Before sending a codec list in FastStart and TCS messages, the codec list 
must be sorted according to the Best Bandwidth or Best Quality policy. This 
is determined by the following: 

• the zone configuration of the Internet Telephone / DSP involved in the 
call 

• the zone configuration of the virtual trunk used for the call 

Codec list sorting 

There are two methods for sorting the codec list: 

1 Best Quality (BQ) sorting - The codec list is sorted so that the first codec 
in the list is the best quality codec, the second codec is the second best 
quality codec in the list, and so on. 

2 Best Bandwidth (BB) sorting - The codec list is sorted so that the first 
codec in the list is the best bandwidth codec, the second codec is the 
second best bandwidth codec in the list, and so on. 
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Table 34 on page 149 shows the codec list sorting order for the BQ and BB 
codecs. To know if a codec is best quality (as compared to another codec), 
refer to the lists in columns 1 and 2. To know if a codec is best bandwidth (as 
compared to another codec), refer to the lists in columns 3 and 4. The best 
quality or bandwidth codec is listed at the top of the column. 


Table 34 

BQ and BB codec sorting lists 


Best Quality (BQ) Sorting 

Best Bandwidth (BB) Sorting 

For mu-law systems 

For a-law systems 

For mu-law systems 

For a-law systems 

G.71 _mu _law_10msec 

G.711_a_law_10msec 

G.729AB_50msec 

G.729AB 50msec 

G.711 _mu Jaw_20msec 

G.711_ajaw_20msec 

G.729AB _40msec 

G.729AB _40msec 

G.711_mu_law_30msec 

G.711_a_law„30msec 

G.729AB _ 30 msec 

G.729AB_30msec 

G.711_ajaw__10msec 

G.711_mu_law_10msec 

G.729AB_20msec 

G.729AB_20msec 

G.711_ajaw_20msec 

G.711_mujaw_20msec 

G.729AB_ 10msec 

G.729AB_10msec 

G.711 _a Jaw_30msec 

G.711_ mu law__30msec 

G.729A _ 50msec 

G.729A 50msec 

G.729A_10msec 

G.729A_10msec 

G.729A40msec 

G.729A_40msec 

G.729A_ 20msec 

G.729A_20msec 

G.729A_30msec 

G.729A_30msec 

G.729A 30msec 

G.729A„30msec 

G.729A 20msec 

G.729A_20msec 

G.729A_40msec 

G.729A_40msec 

G.729A 10msec 

G.729A_10msec 

G.729A _50msec 

G.729A_50msec 

G.723.1 _5.3kbpsJ30ms 

G.723.1_5.3kbps_30ms 

G.729AB_10msec 

G.729AB_ 10msec 

G.723.1 _6.4kbps_30ms 

G.723.1 _6.4kbps _30ms 

G.729AB._20msec 

G.729AB_20msec 

G .711 _ mu_law _30msec 

G.711_a_law_30msec 

G ,729AB_30msec 

G.729AB_30msec 

G.711_mu_law_20msec 

G.711._a_Jaw20msec 

G.729AB_40msec 

G.729AB_40msec 

G.711_mujaw_10msec 

G.711_a_law_10msec 

G.729AB_50msec 

G.729AB 50msec 

G .711 ^a_)aw__30msec 

G.711_mu Jaw_30msec 

G.723.1_5.3kbps_30ms 

G.723.1_5.3kbps_30ms 

G.711_a_law_20msec 

G.711_mu_law_20msec 

G.723.1_6.4kbpsJ30ms 

G.723.1_6.4kbps_30ms 

G.711 _a _law_10msec 

G.711_mujaw_10msec 

T.38 

T.38 

T.38 

T.38 

G.71 ICC 

G.71 ICC 

G.711CC 

G.71 ICC 
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Codec selection for Succession CSE 1000 Rel 2.0 

For every virtual trunk call, a codec must be selected before the media path is 
opened. 

When a call setup with the FastStart procedure is used, the terminating node 
selects a common codec and sends the selected codec to the originating node. 
For a call modification (media redirection) or for a call setup using the 
SlowStart procedure, the codec selection occurs on both nodes. Each node has 
two codec lists: its own list and the far-end’s list. To select the same codec on 
both nodes, it is essential to use the same codec selection algorithm on both 
nodes. 

For the codec selection, both the near- and far-end codec lists are retrieved: 

• The far-end list is not modified because it is already sorted when it is 
received (in FastStart or TCS message). 

• The near-end list is sorted and then expanded to include lower payloads, 
the same way it is done before sending the codec list in FastStart 
message. 

The following conditions are met before codec selection occurs: 

• There are two codec lists: 

— The near-end list is the codec list of the local unit. 

— The far-end list is the codec list received from the far end. 

• Each codec list can contain more than one payload size for a given codec 
type. The codec list depends on the codec configuration. 

• Each codec list is sorted by order of preference. The first codec in the 
near end list is the near end’s most preferred codec and the first codec in 
far end list is the far end’s most preferred codec, and so on. 
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Once the above conditions are met, a codec selection algorithm is used to 
select the codec to be used for a call. There are two different codec selection 
algorithms: 

1 H.323’s Master/Slave algorithm 

2 Best Bandwidth Codec Selection algorithm 

H.323’s Master/Slave algorithm 

The codec selection algorithm proposed by the H.323 standard involves a 
Master/Slave negotiation, initiated each time two nodes exchange their 
capabilities (TCS message). The Master/Slave information decides that one 
node is Master and the other node is Slave. The outcome of the Master/Slave 
negotiation is not known in advance, it is a random result: one node could be 
Master then Slave (or vice versa) during the same call. 

• The Master node uses its own codec list as the preferred one. From the 
far-end list, it finds the common codec. 

The Master gets the first codec in its own list (Codec 1). The Master then 
checks the far-end list to see if Coded is a common codec (that is, is 
Codec! also listed in the far-end list). If Coded is common to both lists. 
Codec! becomes the selected codec. Otherwise, the Master obtains the 
second codec from its own list and repeats the search in the far-end list, 
and so on. 

• The node which is Slave uses the far end list as the preferred list. The 
Slave selects a codec from the far end list and then searches in its own 
list to find the common codec. 

The issues caused by the Master/Slave algorithm arc due to the random nature 
of the Master/Slave information. The codec that is selected and used during a 
virtual trunk cal! cannot be pre-determined. This issue can make bandwidth 
usage calculations and bandwidth management difficult. 
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Known issues include: 

• After an on-hold and off-hold scenario (that triggers Master/Slave 
negotiation), the codec used for the restored call can be different than the 
codec used before the call was placed on hold. The Master/Slave 
information could have been changed when the call was on hold. 

• Since the terminating end of a call is always the Master, a call from 
telephone 1 (node 1) to telephone2 (node2) can use a different codec than 
a call from telephone2 (node2) to telephone 1 (nodel). 

• For tandem calls, the Master/Slave information is not relevant. That is, 
the Master/Slave information is designed to be used only between two 
nodes, not among three or more nodes. The Master/Slave algorithm 
makes the codec selection for tandem calls more complex and inefficient. 

To solve the issues, another codec selection algorithm was needed. This new 
algorithm is called the Best Bandwidth Codec Selection algorithm and it is 
not based on the unpredictable Master/Slave information. 

The new codec algorithm is used for virtual trunk calls between Nortel 
Networks equipment, since any change to the Master/Slave algorithm implies 
a change to the H.323 standard. However, the H.323’s Master/Slave 
algorithm is used when there is a virtual trunk call between Nortel Networks 
equipment and third-party equipment. 
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Best Bandwidth Codec Selection algorithm 

The Best Bandwidth Codec Selection algorithm was implemented to solve 
the issues caused by the H.323 Master/Slave algorithm. The Best Bandwidth 
algorithm selects one common codec based on two codec lists. With this 
algorithm, every time the selection is done using the same two lists, the 
selected codec is always the same. 

The “Best Bandwidth” codec selection is based on the codec type only; it does 
not take into account the fact that some codecs, while generally using less 
bandwidth, consume more bandwidth than others at certain payload sizes. 

• This algorithm obtains the first codec in the near-end list that is also in 
far end list (codec is the same type and has the same payload size). Call 
the selected codec C1. 

• Get the first codec in far end list that is also in near-end list (same type, 
same payload size). This codec is C2. 

• Between Cl and C2, the codec that is selected is considered as the best 
bandwidth codec type. To determine which codec type is the best 
bandwidth, the following rules are used: 

— a G.729AB codec is considered as Best Bandwidth compared to 
G.729A. G.723.1, G.71 l_muLaw, and G.71 l_aLaw codecs 

— a G.729A codec is considered as Best Bandwidth compared to 
G.723.1,G.71 l_muLaw, and G.71 l_aLaw codecs 

— a G.723.1 codec is considered as Best Bandwidth compared to a 
G.71 l_muLaw and G.71 l_aLaw codec 

— a G.7I l_muLaw codec is considered as Best Bandwidth compared 
to a G.71 l_aLaw codec 
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Table 35 shows the codec that would be selected between any two codecs. For 
example, if the two codecs are the G.729A and G.723.1, the selected codec is 
the G.729A. 


Table 35 

Best Bandwidth codec selection between any two codecs types 


Codec type 

G.711 aLaw 

G.711_muLaw 

G.729A 

G.729AB 

G.723.1 

G.711 aLaw 

G.711_aLaw 

G.711_muLaw 

G.729A 

G.729AB 

G.723.1 

G.711 muLaw 

G.711_muLaw 

G.711_muLaw 

G.729A 

G.729AB 

G.723.1 

G.729A 

G.729A 

G.729A 

G.729A 

G.729AB 

G.729A 

G.729AB 

G.729AB 

G.729AB 

G.729AB 

G.729AB 

G.729AB 

G.723.1 

G.723.1 

G.723.1 

G.729A 

G.729AB 

G.723.1 
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Calculate IP Line traffic requirements 

The technician must forecast the hundreds of call seconds for each hour 
(CCS) traffic that the Meridian 1 and Succession CSE 1000 processes 
through the IP Line network. CCS traffic generated by an Internet Telephone 
is similar to that of a digital telephone. The following procedures calculate the 
bandwidth required to support given amounts of traffic. 

The procedures require the following data: 

• CCS/CCS rating of Internet Telephone 

• number of Internet Telephones 

• number of subnets/servers accessed by the Internet Telephones 
Note: Base all traffic data on busy hour requirements. 

The result of the calculation provides estimated values for the following: 

• total TLAN bandwidth requirement 

• WAN bandwidth requirement for each subnet or server/router 

The technician must consider the impact of incremental IP Line traffic on 
routers and LAN resources in the intranet. LAN segments can become 
saturated, and routers can experience high CPU use. A customer must 
consider re-routing scenarios in a case where a link is down. 

TLAN traffic calculations 

To calculate the total TLAN requirement, add together all sources of traffic 
destined for the Internet Telephony network using the same LAN. The data 
rate for a TLAN is the total bit rate. The total subnet traffic is measured in 
Erlangs. An Erlang is a telecommunications traffic measurement unit and it 
is used to describe the total traffic volume of one hour. Network designers use 
these measurements to track network traffic patterns. To calculate the TLAN 
traffic, follow Procedure 2. 
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Procedure 2 

Calculating TLAN traffic 

1 Total subnet traffic is the sum of (measured in Erlangs): 

• number of Internet Telephones x CCS/CCS rating) 

• voice gateways on Voice Gateway Media Card 

• WAN connection 

Note: Each source of traffic has a different CCS rating. Calculate the 
subnet traffic for each source of traffic and add the amounts to get the 
total. 

2 Use the number of Erlangs to calculate the equivalent number of lines by 
using the calculator at the following Web site: 

http://www.erlang.com/calculator/erlb 

Note: Assume a blocking factor of 1% (0.010). 

3 Find the TLAN bandwidth use (Kbps) in Table 36 on page 158 based on 
the codec used for the traffic source. 

4 Calculate the bandwidth of a subnet using the following calculation: 

Bandwidth for each subnet equals the total number of lines multiplied by 
the TLAN bandwidth usage, that is: 

Subnet bandwidth = Total number of lines x TLAN bandwidth usage 

5 Repeat steps 1 to 4 for each subnet. 

6 To calculate the total TLAN traffic, add the total bandwidth for each subnet 
calculation. 


End of Procedure 
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Table 36 on page 158 lists the bandwidth consumed by the various payload 
sizes of each codec. The Call Server uses the values in the columns labeled 
"TLAN Bandwidth". It looks up these values and subtracts them from the 
available zone bandwidth to determine if a zone has sufficient bandwidth for 
the call. 

The "TLAN Bandwidth" values contain the total IP and Ethernet packet 
overhead of 78 bytes, including the 8 byte preamble and minimum 12 byte 
inter-packet gap. These are often excluded from bandwidth calculations but 
must be included to give a true indication of the bandwidth used. The Call 
Server assumes a Half Duplex Ethernet connection (again, to cover the worse 
case), so the bandwidth values shown are twice what is normally listed for a 
Full Duplex link. 

The columns labeled "Base WAN Bandwidth" provide the data for the 
payload plus IP overhead without the Ethernet interface overhead. This data 
provides the basis for any WAN bandwidth calculations. The overhead 
associated with the particular WAN facility, such as Frame Relay, is added to 
the base value to determine the total bandwidth used. The values shown are 
for a duplex link, so if the WAN facility is Half Duplex, the values should be 
doubled. 

Note: The Call Server is unaware of the particulars of the WAN facility 

and always uses the values shown in the "TLAN Bandwidth" columns. 
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Table 36 

TLAN and WAN IP bandwidth usage for each bi-directional IP conversation 






TLAN Bandwidth 

Base WAN Bandwidth 

Codec 

type 

Packet 

duration 

(ms) 

Voice 

payload 

(bytes) 

VAD 

Peak Average 

bandwidth bandwidth 
(Kbps) (Kbps) 

Peak 

bandwidth 

(Kbps) 

Average 

bandwidth 

(Kbps) 

G.711 
(64 Kbps) 

10 

80 

Off 

252.80 

252.80 

96.00 

96.00 

20 

160 

Off 

190.40 

190.40 

80.00 

80.00 

30 

240 

Off 

169.60 

169.60 

74.67 

74.67 

G.729A 
(8 Kbps) 

10 

10 

Off 

140.80 

140.80 

40.00 

40.00 

20 

20 

Off 

78.40 

78.40 

24.00 

24.00 

30 

30 

Off 

57.60 

57.60 

18.67 

18.67 

40 

40 

Off 

47.20 

47.20 

16.00 

16.00 

50 

50 

Off 

40.96 

40.96 

14.40 

14.40 

G.729AB 
(8 Kbps) 

10 

10 

On 

140.80 

84.48 

40.00 

24.00 

20 

20 

On 

78.40 

47.04 

24.00 

14.40 

30 

30 

On 

57.60 

34.56 

18.67 

11.20 

40 

40 

On 

47.20 

28.32 

16.00 

9.60 

50 

50 

On 

40.96 

24.58 

14.40 

8.64 

G.723.1 
(6.3 Kbps) 

30 

24 

Off 

54.40 

54.40 

17.07 

17.07 

G.723.1 
(5.3 Kbps) 

30 

24 

Off 

54.40 

54.40 

17.07 

17.07 
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Note 1: The bandwidth estimates in Table 36 on page 158 assume a Half 
Duplex LAN/WAN connection and show the total bandwidth (both 
directions) used. For a Full Duplex link, such as Full Duplex Ethernet, 
the table’s bandwidth estimates should be divided by two to determine 
the bandwidth used in one direction. However, the Call Server assumes 
the worse case (Half Duplex) when calculating the bandwidth used for 
each call against a Zone's bandwidth capacity. 

Note 2: The "TLAN Bandwidth" overhead is assumed to be for 
Ethernet connections and is comprised of 8 bytes of Ethernet Preamble, 
14 bytes of Ethernet, 20 bytes of IP, 8 bytes of UDP, and 12 bytes of RTP 
Header, plus 4 bytes of Ethernet check sum and 12 bytes of inter-packet 
gap. The total packet payload overhead is 78 bytes. 

Note 3: Different transport types have slightly different bandwidth 
requirements. 

Note 4: The average bandwidth is reduced from the peak bandwidth by 
the use of silence suppression (VAD). 

Note 5: The reduction due to VAD is assumed to be 40%. 

Note 6: The "Base WAN Bandwidth" overhead includes only the IP 
packet overhead of 20 bytes of IP, 8 bytes of UDP, and 12 bytes of RTP 
Header. The total packet payload overhead is 40 bytes. The values shown 
are for a Full Duplex data rate. Double the values if the WAN facility is 
Half Duplex. 
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TLAN engineering example 

The following is an example of calculating TLAN bandwidth assuming Half 
Duplex links. 

1 Subnet A: 28 Internet Telephones x 6 CCS/36 = number of Erlangs 
Using G.729AB 30 msec, TLAN bandwidth usage is 57.6 Kbps. 

Subnet A bandwidth = 4.66 lines x 57.6Kbps = 268.4 Kbps 

2 Subnet B: 72 Internet Telephones, average 5 CCS/Internet Telephone 
Subnet B total Erlangs = 72 x 5/36 = 10 

Subnet B bandwidth = 10 x 57.6 = 576 Kbps 

3 Subnet C: 12 Internet Telephones, average 6 CCS/Internet Telephone 
Subnet C total Erlangs = 12 x 6/36 = 2 

Subnet C bandwidth = 2 x 57.6 = 115.2 Kbps 

4 Calculate the TLAN Bandwidth by adding each subnet bandwidth: 

TLAN Bandwidth = 268.4 + 576 + 115.2 = 959.6 Kbps 

- End of Example - 
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Assess WAN link resources 

If IP Line traffic is routed over an intranet, the technician must assess the 
status of the network. For a locally connected Internet Telephone, if calls are 
routed to the PSTN, the calls affect only the capacity of the TLAN. 

When calls are routed through an intranet, WAN links are frequently the 
source of capacity problems in the network. Unlike LAN bandwidth, which 
is virtually free and easily implemented, WAN links take time to obtain 
financial approval, provision, and upgrade. It is important to assess the state 
of WAN links in the intranet prior to implementing the IP Line network. 

WAN traffic calculations 

For data rate requirements for the intranet route, calculation is based on 
duplex channels. The data rate for a WAN is the duplex data rate. For 
example, 128 Kbps on the LAN is equal to a 64 Kbps duplex channel on the 
WAN. Use the following procedure to calculate data rate requirements for the 
intranet route. The effects of Real-time Transport Protocol (RTP) header 
compression by the router are not considered in these calculations but must 
be included where applicable. 

Procedure 3 
Calculating WAN traffic 

1 Total subnet traffic = Number of Internet Telephones x CCS/Internet 
Telephone. 

2 Convert to Erlangs: 

Total CCS / 36 (on the Half Duplex LAN) 

3 Find WAN bandwidth usage (Kbps) from the “WAN Base Bandwidth” 
columns of Table 35 on page 154. 

4 Bandwidth for each subnet = Total Erlangs x WAN bandwidth usage. 

5 Multiply bandwidth of each subnet by 1.3 to adjust for traffic peaking. 

6 Repeat the procedure for each subnet. 
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7 Adjust WAN bandwidth to account for WAN overhead depending on the 
WAN technology used: 

• ATM (AAL1): multiply subnet bandwidth x 1.20 (9 bytes overhead/44 
bytes payload) 

• ATM (AAL5): multiply subnet bandwidth x 1.13 (6 bytes overhead/47 
bytes payload) 

• Frame Relay: multiply subnet bandwidth x 1.20 (6 bytes overhead/30 
bytes payload - variable payload up to 4096 bytes) 

Note: Each WAN link must be engineered to be no more than 80% of its 
total bandwidth if the bandwidth is 1536 Kbps or higher (T1 rate). If the 
rate is lower, up to 50% loading on the WAN is recommended. 

- End of Procedure - 


WAN engineering example 

The following is an example of calculating the WAN bandwidth. 

1 Subnet A: 36 Internet Telephones, average 6 CCS/Internet Telephone 

• Total Erlangs = 36 x 6/36 = 6 

• For G.729AB 50 msec, WAN bandwidth usage is 14.4 Kbps. 

• Subnet A WAN bandwidth = 14.4 x 6 = 86.4Kbps 

• Subnet A WAN bandwidth with 30% peaking 
= 86.4 x 1.3 

= 112.32 Kbps 


2 Subnet B: 72 Internet Telephones, average 5 CCS/Internet Telephone 

• Total Erlangs = 72 x 5/36 = 10 

• Subnet B WAN bandwidth = 14.4 x 10 = 144 Kbps 

• Subnet B WAN bandwidth with 30% peaking 
= 144 x 1.3 

= 187.2 Kbps 
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3 Subnet C: 12 Internet Telephones, average 6 CCS/Internet Telephone 

• Total Erlangs = 12 x 6/36 = 2 

• Subnet C WAN bandwidth = 14.43 x 2 = 28.8 Kbps 

• Subnet C WAN bandwidth with 30% peaking 
= 28.8 x 1.3 

= 37.44 Kbps 

4 If the WAN is known to be an ATM network (AAL1 ), the estimated 
bandwidth requirements are: 

• Subnet A WAN bandwidth with ATM overhead 
= 112.32 x 1.2 

= 134.78 Kbps. 

• Subnet B WAN bandwidth with ATM overhead 
= 187.2 x 1.2 

= 224.64 Kbps 

• Subnet C WAN bandwidth with ATM overhead 
= 37.44 x 1.2 

= 44.93 Kbps 

Note: Bandwidth values can vary slightly depending on the transport 
type. 


End of Example 
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VoIP bandwidth management zones 

Each Internet Telephone and Voice Gateway Media Card port is assigned a 
zone number in which it resides. The zone indicates the VoIP bandwidth 
management zone of the IP devices so that IP bandwidth can be managed 
within locations and between locations. This enables users to avoid quality 
degradation because of insufficient bandwidth for active connections. 

For example, a branch office or telecommuter location can have more Internet 
Telephones than are supported by the IP link to that location (for example, 
128 Kbps bandwidth with 10 Internet Telephones). 

The zones are also used to determine if voice compression and silence 
detection is used for a connection. 

Zone properties are defined in LD 117. Up to 256 zones can be configured. 
The Meridian 1 and Succession CSE 1000 systems use the zones for 
bandwidth management. New calls are blocked when the bandwidth limit is 
reached. 

Each zone has four parameters. The prompt lists the parameters as p 1, p2, p3, 
p4, and p5: 

• pi - The total bandwidth available for intrazone calls. 

• p2 - The preferred strategy for the choice of codec for intrazone calls 
(that is, preserve best quality or best bandwidth). 

• p3 - The total bandwidth available for interzone calls. 

• p4 - The preferred strategy for the choice of the codec for interzone calls. 

• p5 - The zone resource type; the type is either shared or private. 
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The Call Server uses the values shown in Table 36 on page 158 when 
calculating the bandwidth each call uses in a zone. The Call Server cannot 
determine whether the LAN/WAN connection is Half or Full Duplex. 
Therefore, the Call Server assumes the worse case, and subtracts the 
bandwidth consumed on a Half Duplex link by the codec and voice payload 
combination from the available zone bandwidth. 

This should be considered when entering a zone's intra and inter bandwidth 
values in LD 117. If the zone has Full Duplex links, then the bandwidth 
entered should be doubled. For example, with a 100 BaseT Full Duplex LAN, 
the intra zone bandwidth can be configured to be 200000. 

If no IP voice zones are configured, zone 0 operates as a default zone with no 
restrictions on bandwidth usage. If no IP voice zones are configured in 
LD 117, zone 0 can be configured for 1PTN in LD 14, and for virtual line in 
LD 11 as a default zone. However, if any additional zones are required, 
zone 0 must be first configured in LD 117 if it is referenced by any Internet 
Telephone or 1TG Physical TNs (1PTN). If zone 0 is not configured first, then 
all calls in zone 0 are labeled as soon as another zone is configured in LD 117. 


a CAUTION 

/|\ When moving an internet Telephone, the Administrator 

/ f \ should check and change, if necessary, the telephone’s 

/ * \ zone assignment in LD 11. See Software Input/Output: 

Administration (553-3001-311). 


CAUTION 

Zone 0 must be configured in LD 117 before other zones 
are configured or all calls associated with zone 0 are 
blocked. 


Figure 9 on page 166 shows an example of bandwidth management. 
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Figure 9 

Bandwidth management example 



r 


Zone Table 


Zone Intrazone 

Interzone 

1 

BQ: 

100,000 

BB: 

500 

2 

BQ: 

10,000 

BB: 

128 

3 

BQ: 

10,000 

BB: 

500 


500 
Kbps 

om _ J Remote 

Router '■—- LAN 



Two Codecs Can Be Configured 
One for Best Quality - e g. G.711 
One for Best Bandwidth - e g. G.729A 
Bandwidth Consumption Tracked Within a 
Zone and Between Zones 
Calls Block if Insuficient Bandwidth Available 


Zone 3 


Note: Bandwidth values given are for available bandwidth for VoIP and not for total bandwidth capacity. 
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Relationship between zones and subnets 

Internet Telephones and Voice Gateway Media Cards gateway ports are 
assigned to zones based on the bandwidth management requirements of the 
particular installation. Devices in different subnets must traverse a router to 
communicate and can lie on different ends of a WAN facility. When Internet 
Telephones and gateway ports are in different subnets, the network facilities 
between them must be examined to see if it warrants placing the separated 
devices in different zones. 

It is not necessary to always assign different zones. For instance, there can be 
different subnets within a LAN interconnected by router(s) with sufficient 
bandwidth. The Internet Telephones and gateway channels spread across 
them could all reside in a single zone. However, if there is a WAN facility 
with limited bandwidth between two subnets, the devices on the opposite 
ends should be placed in different zones so the bandwidth across the WAN 
can be managed. 


Link utilization assessment 

To assess the link utilization, follow the steps in Procedure 4. 

Procedure 4 

Assessing link utilization 

1 Obtain a current topology map and link utilization report of the intranet. 

2 Visually inspect the topology map to reveal which WAN links are likely to 
be used to deliver IP Line traffic. Alternately, use the traceroute tool (see 
“The following measuring tools are based on the ICMP (Internet Control 
Messaging Protocol):” on page 175). 

3 Find out the current utilization of the WAN links. For example, the link’s 
use can be averaged over a week, a day, or an hour. 

4 Obtain the busy period (peak hour) use of the link. 

5 Since WAN links are Full Duplex and data services exhibit asymmetric 
traffic behavior, obtain the utilization of the link representing traffic flowing 
in the heavier direction. 

6 Assess how much spare capacity is available. 

Enterprise intranets are subject to capacity planning policies that ensure 
that capacity usage remains below some pre-determined use level. 
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For example, a planning policy states that the use of a 56 Kbps link during 
the peak hour must not exceed 50%; for a T1 link, the threshold is higher, 
perhaps 80%. The carrying capacity of the 56 Kbps link would therefore 
be 28 Kbps, and for the T1, 1.2288 Mbps. In some organizations, the 
thresholds can be lower than that used in this example; in the event of link 
failures, there needs to be spare capacity for traffic to be re-routed. 

7 The difference between the current capacity, and its allowable limit, is the 
available VoIP capacity. 

For example, a T1 link used at 48% during the peak hour, with a planning 
limit of 80% has an available capacity of about 492 Kbps. 

- End of Procedure - 

Estimating network loading due to IP Line 

At this point, the technician has enough information to “load” the IP Line 
traffic on the intranet. The following example illustrates how this is done on 
an individual link. Not only must the IP Line traffic be taken into account but 
also the 1TG Trunk traffic. 

Example: 

The intranet has a topology as shown in Figure 10 on page 169, and the 
technician wants to predict the amount of traffic between the IP Telephony 
node and corporate intranet. From the Calculate IP Line traffic requirements 
section (see page 155) and traceroute measurements, the traffic is collected 
between the IP Telephony node and subnet A, the IP Telephony node and 
subnet B, and the IP Telephony node and Router/Server C. 

To complete this example, the traffic flow from the IP Telephony node to all 
routes needs to be totaled to determine the load to the link (TLAN). 
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Figure 10 

An IP Line intranet with subnetworks 
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Decision: Is there sufficient capacity? 

A link is defined as the route between the IP Telephony node and a subnet. 
Table 37 organizes the computations for each link, so that the available link 
capacity can be compared against the additional Voice Gateway Media Card 
load. For example, on the link from the IP Telephony Node to Subnet C, there 
is plenty of available capacity (568 Kbps) to accommodate the additional 
24 Kbps of Voice Gateway Media Card traffic. 


Table 37 

Link Utilization Summary Example 


Link 


Utilization (%) 


Incremental 

Voice 
Gateway 
Media Card 

Traffic 

(Kbps) 


End¬ 

points 

Capacity 

(Kbps) 

Threshold 

Used 

Available 

capacity 

(Kbps) 

Sufficient 

capacity? 

IPLine_Node1 

- SubnetA 

1536 

80 

75 

76.8 

72.5 

Yes 

IPLine^Nodel 
- SubnetB 

1536 

80 

50 

460.8 

120.9 

Yes 

IPLine_Node1 
- SubnetC 

1536 

80 

48 

492 

24.2 

Yes 


Some network management systems have network planning modules that 
compute network flows in the manner just described. These modules provide 
detailed and accurate analysis as they take into account actual node, link, and 
routing information. They also help the technician assess the network 
resilience by conducting link and node failure analysis. By simulating 
failures, re-loading the network, and re-computing routes, the modules 
indicate where the network can run out of capacity during failures. 

Insufficient link capacity 

If there is insufficient link capacity, consider upgrading the link's bandwidth. 
RTP header compression can be implemented on the WAN router if it is a 
narrow bandwidth WAN link (less than 1.5 Mbps). 
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Set service parameters 

Quality of Service (QoS) mechanism 

The QoS requested from the IP network is controlled by the DiffServ Code 
Point (DSCP). QoS is controlled by setting the DSCP field in the IP header 
for both the Voice Gateway Media Card and the Internet Telephone. 
Individual values are configurable for the voice and control DSCP values and 
can be configured to a number between 0 and 63 inclusive. DSCP values 
control per hop behavior for packet forwarding for the router. The values are 
set once for each system and apply to all packets sent by the Voice Gateway 
Media Card and the Internet Telephone. 

If DiffServ is implemented on the network, ask the network administrator for 
the default values that are used in the system. The recommended 
configuration values are: 

• voice DSCP: 46 - Expedited Forwarding (EF) per hop behavior 

• control DSCP: 40 - Class Selector 5 (CS5) 

Note: OTM and Element Management have 46 and 40 as the default 
values. 

In some cases, the IP Network Administrator can set the DiffServ field at the 
edge of the QoS-controlled network by routers at the network edge. DiffServ 
can be set based on source or destination address, or port number. The Voice 
Gateway Media Card and Internet Telephone can be configured to have RTP 
voice UDP port numbers in a specific range. 
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Voice Gateway Media Card and Internet Telephone port 
numbers 

Table 38 lists the UDP ports used for IP Line to Internet Telephone 
communications. 


Table 38 

UDP ports used for IP Line to Internet Telephone communications (Part 1 of 2) 


Port usage 

Port number mapping 

Signaling 

(UNIStim over RUDP link) 

IP Line port 5100 to Internet Telephone port 5000 

Note: Port 5000 is fixed by the Internet Telephone. 

Voice (Media) 

RTP: 

• ITG-P Line Card 

IP Line port 5200 - 5246 (even numbers) to 

Internet Telephone port 5200 

• Succession Media Card 

IP Line port 5200 - 5262 (even numbers) to 

Internet Telephone port 5200 

Note: The OTM user interface enables setting a "Voice Port" 
value; this sets both the Internet Telephone RTP port and the 
starting port for the IP Line gateway's RTP port range. 5200 is 
the default. The Internet Telephone uses port 5200 while the IP 
Line gateway channels [0-23] use the even port numbers in the 
range [5200 - 5246]. 

RTCP: 

• ITG-P Line Card 

IP Line port 5201 - 5247 (odd numbers) to 

Internet Telephone port 5201 

• Succession Media Card 

IP Line port 5201 - 5263 (odd numbers) to 

Internet Telephone port 5201 

Note: The RTCP port numbering is based on each channel's 

RTP port + 1. Therefore, the RTCP port range is dependent on 
the configuration for RTP port. 
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Table 38 

UDP ports used for IP Line to Internet Telephone communications (Part 2 of 2) 


Port usage 

Port number mapping 


Registration 

IP Line ports 4100 and 7300 to Internet Telephone port 5000 


i2002/i2004 Internet 
Telephone 
firmware download 

TFTP standard port 69 



Table 39 lists the other UDP ports used by the IP Line. 


Table 39 

Other UDP ports used by the IP Line 


Port usage 

Port number mapping 


Bidirectional TPS to TPS signaling (intercard) 

16543 


SNTP signaling 

20000 + IP Telephony node number 


BOOTP server on Leader 

67 (standard) 


BOOTP client on Followers 

68 (standard) 


SNMP on ELAN interface 

161 (standard) 


RUDP signaling with Meridian 1 core CPU on 
ELAN interface 

15000 

15001 
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Measure intranet Quality of Service 

Utilization of the existing data network must be assessed to determine the 
quality of voice services it can support. 

End-to-end delay and error characteristics of the intranet must be measured 
so that the technician can set realistic QoS expectations for intranet voice 
services. 


WARNING 

/•\ Network designers must be aware of traffic calling 

/ I \ patterns between any combination of Internet 

Telephones and gateway channels, and must plan the 
capacity of connecting elements to handle the expected 
traffic. 


The use of measuring tools requires a source node and a destination node. The 
source node can be a “PING” (see page 175) host on a LAN segment attached 
to the router intended to support the node. The destination node can be a 
remote subnet. The requirement is briefly described as follows. 

Note: Ensure that the 1TG network DiffServ bytes are set to their 
intended operational values before taking measurements. 

Criteria 

• End-to-end packet delay: Packet delay is the point-to-point, one-way 
delay between the time a packet is sent to the time it is received at the 
remote end. It is comprised of delays at the Voice Gateway Media Card, 
Internet Telephone, and the IP network. To minimize delays, the IP 
Telephony node and Internet Telephone must be located to minimize the 
number of hops to the network backbone or WAN. 

Note: To ensure good voice quality, an end-to-end delay of <= 50 ms is 
recommended on the IP network. This does not include the built-in delay 
of the Voice Gateway Media Card and Internet Telephone. 
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• End-to-end packet loss: Packet loss is the percentage of packets sent 
that do not arrive at their destination. Transmission equipment problems, 
packet delay, and network congestion cause packet loss. In voice 
conversation, packet loss appears as gaps in the conversation. Sporadic 
loss of a few packets can be more tolerable than infrequent loss of a large 
number of packets clustered together. 

Note: For high-quality voice transmission, the long-term average packet 
loss between the Internet Telephones and the Voice Gateway Media Card 
TLAN interface must be < 1%, and the short-term packet loss must not 
exceed 5% in any 10-second interval. 

Packet loss on the ELAN interface can cause: 

— communication problems between the Call Server and the Voice ' 
Gateway Media Cards 

— lost SNMP alarms 

— incorrect status information on the OTM console 

— other signaling related problems 

Note: Since the ELAN network is a Layer 2 Switched LAN, the packet 
loss must be zero. If packet loss is experienced, its source must be 
investigated and eliminated. For reliable signaling communication on the 
ELAN interface, the packet loss must be < 1 %. 

The following measuring tools are based on the ICMP (Internet Control 
Messaging Protocol): 

• PING (sends ICMP echo requests) 

• Traceroute (sends packets to unequipped port numbers and processes to 
create ICMP destination unavailable messages). 

Both PING and traceroute are basic measuring tools that can be used to assess 
the IP Line network. They are standard utilities that come with most 
commercial operating systems. PING is used to measure the round-trip delay 
of a packet and the percentage of packet loss. Traceroute breaks down delay 
segments of a source-destination pair and any hops in-between to accumulate 
measurements. 
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There are several third-party applications that perform data collection similar 
to PING and traceroute. In addition, these programs analyze data and plot 
performance charts. The use of PING and traceroute to collect data for 
manual analysis is labor intensive; however, they provide information as 
useful as the more sophisticated applications. 

The following analysis use PING/traceroute data for discussion, although it 
is likely in most situations a third-party application is used. 

Destination Types 

To a remote subnet 

This configuration involves an intranet subnet that is attached to a number of 
Internet Telephones, that becomes an intermediate hop in the path delivering 
voice packets between the Internet Telephone and the IP Line network. 
Collect the delay measurement between the PING host and the subnet server. 

Measuring end-to-end network delay 

The basic tool used in IP Line networks to measure end-to-end network delay 
is the PING program. PING takes a delay sample by sending an ICMP packet 
from the host of the PING program to a destination server, and waits for the 
packet to make a round trip. 

To ensure the delay sample results are representative of the IPLine_Nodel: 

a Attach the PING host to a “healthy” LAN segment. 

b Attach the LAN segment to the router intended to support the IP 
Telephony node. 

c Choose a destination host by following the same critical guidelines 
as for the source host. 

The size of the PING packets can be any number; the default is 60 bytes. 


553-3001-204 Standard 4.00 November 2002 





IP Network Engineering Guidelines 


Page 177 of 724 


Sample PING output: 

IPLine_Nodel% PING -s suhnetA 60 
PING subnetA (10.3.2.7): 60 data bytes 
68 bytes from (10.3.2.7): icmp_seq=0 ttl=225 time=97ms 
68 bytes from (10.3.2.7): icmp_seq=0 ttl=225 time=100ms 
68 bytes from (10.3.2.7): icmp seq=0 ttl=225 time=102ms 
68 bytes from (10.3.2.7): icmp seq=0 ttl=225 time=97ms 
68 bytes from (10.3.2.7): icmp seq=0 ttl=225 time=95ms 
68 bytes from (10.3.2.7): icmp seq=0 ttl=225 time=94ms 
68 bytes from (10.3.2.7): icmp_seq=0 ttl=225 time=112ms 
68 bytes from (10.3.2.7): icmp_seq=0 ttl=225 time=97ms 

A? 

— IPI.ine_Nodel PING Statistics — 

8 packets transmitted, 8 packets received, 0 % packet loss 
round-trip (ms) min/avg/max = 94/96/112 
Note: PING results can vary. 

Assessment of sample PING output 

Note: The round-trip time (rtt) is indicated by the time field. 

The rtt from the PING output varies. It is from repeated sampling of rtt that a 
delay characteristic of the intranet can be obtained. To obtain a delay 
distribution, the PING tool can be embedded in a script that controls the 
frequency of the PING probes, timestamps and stores the samples in a raw 
data file. The file can then be analyzed later using a spreadsheet or another 
application. The technician can also check if the intranet’s network 
management software has any delay measurement modules that can obtain a 
delay distribution for a specific route. 
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Delay characteristics vary depending on the site pair and the time-of-day. The 
site pair is defined as the measurement between the host IP Line and the 
remote subnet (for example, IP Line to subnet A in Figure 10 on page 169). 
The assessment of the intranet must include taking delay measurements for 
each IP Line site pair. If there is a significant variation of traffic on the 
intranet, include PING samples during the intranet's peak hour. For a 
complete assessment of the intranet's delay characteristics, obtain PING 
measurements over a period of at least a week. 

Measuring end-to-end packet loss 

The PING program also reports whether the ICMP packet successfully 
completed its round trip. Use the same PING host setup to measure 
end-to-end error, and in making delay measurement, use the same packet size 
parameter. 

Multiple PING samples must be used when sampling for error rate. Packet 
loss rate (PLR) is the error rate statistic collected by multiple PING samples. 
To be statistically significant, at least 300 samples must be used. Obtaining 
an error distribution requires running PING over a greater period of time. 

Recording routes 

The traceroute tool records routing information for all source-destination 
pairs as part of the network assessment. An example of the traceroute output 
is shown below: 

ipline_nodel‘7r traceroute subnetA 

traceroute to subnetA 10.3.2.7, 30 hops max, 32 byte packets 

1 r6 (10.8.0.1) 1 ms 1 ms 1 ms 

2 r5 (10.18.0.2) 42 ms 44 ms 38 ms 

3 r4 (10.28.0.3) 78 ms 70 ms 81ms 

4 rl (10.3.0.1) 92 ms 90 ms 101ms 

5 subnetA (10.3.2.7) 94 ms 97 ms 95 ms 

The traceroute program is also used to verify whether routing in the intranet 
is symmetric or not for each of the source-destination pairs. This is done using 


553-3001-204 Standard 4.00 November 2002 




IP Network Engineering Guidelines 


Page 179 of 724 


the -g loose source routing option, as illustrated in the following command 
syntax: 

ipline_nodel% traceroute -g subnetA ipline_nodel 

Adjusting PING measurements 
One-way and roundtrip 

The PING statistics are based on round-trip measurements, while the QoS 
metrics in the Transmission Rating model are one-way. Divide the delay and 
packet error PING statistics in half to ensure the comparison is valid. 

Adjustment due to IP Line processing 

The PING measurements are taken from PING host to PING host. The 
Transmission Rating QoS metrics are from end-user to end-user, and include 
components outside the intranet. The PING statistic for delay needs to be 
further modified by adding 93ms to account for the processing and jitter 
buffer delay of the nodes. 

Note: No adjustment needs to be made for error rates. 

If the intranet measurement barely meets the round-trip QoS objectives, the 
technician must be aware of the possibility that the one-way QoS is not being 
met in one of the directions of flow. This can apply even if the flow is on a 
symmetric route due to asymmetric behavior of data processing services. 

Late packets 

Packets that arrive outside the window allowed by the jitter buffer are 
discarded by the IP Line. To determine which PING samples to ignore, 
calculate the average one-way delay based on all the samples. 

To calculate late packets, double the value of the nominal jitter buffer setting. 
For example, assume: 

• the average one-way delay is 50 msec 

• the jitter buffer is set to a nominal (or average) value of 40 msec 

• then the maximum value is 2 x 40 + 50 = 130 msec 


IP Line Description, Installation, and Operation 



Page 180 of 724 IP Network Engineering Guidelines 


Therefore, any packet with a one-way delay of greater than 130 msec is late, 
and must be added to the total number of packets lost. 

Estimate Voice Quality 

The perceived quality of a telephone call is dependent on many factors, such 
as codec characteristics, end-to-end delay, packet loss, and the perception of 
the individual listener. 

The E-Model Transmission Planning Tool is a model used to produce a 
quantifiable measure of voice quality based on relevant factors. Refer to two 
ITU-T recommendations (ITU-T E.107 and E. 108) for more information on 
the E-Model and its application. 

A simplified version of the E-Model is applied to the Internet Telephone to 
provide an estimate of the voice quality that the user can expect based on 
various configuration choices and network performance metrics. 

The simplified E-Model is given below: 

R = 94 - lc - Id - lp 


where: 

lc = codec impairment (see Table 40 on page 181) 

Id = delay impairment (seeTable41 on page 181) 

Ip = packet loss impairment (see Table 42 on page 182) 

Note: This model already takes into account some characteristics of the 
Internet Telephone, and therefore the impairment factors are not 
identical to those shown in the ITU-T standards. 

Refer to Table 43 on page 182 for the translation of R values into user 
satisfaction levels. 
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Table 40 

Impairment factors of codecs 


Codec 

Codec Impairment (Ic) 
(msec frames) 


G.711 

0 


G.729A/AB 

11 - 20 or 30 


G.729A/AB 

16-40 or 50 


G.723.1 (5.3 Kbps) 

19 


G.723.1 (6.3 Kbps) 

15 


Table 41 

Impairment factors due to network delay 
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Table 42 

Impairment factors due to packet loss 


Packet loss (%) 

Packet Lose Impairment (Ip) 

0 

0 

1 

4 

2 

8 

4 

15 

8 

25 


Table 43 

R value translation 


R Value (lower limit) 

MOS 

User Satisfaction 

90 

4.5 

Very satisfied 

80 

4.0 

Satisfied 

70 

3.5 

Some users dissatisfied 

60 

3.0 

Many users dissatisfied 

50 

2.5 

Nearly all users dissatisfied 

0 

1 

_ 

Not recommended 
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Sample scenarios 
Scenario 1 

A local LAN has the following characteristics: 

• G.711 codec 

• 20 msec network delay 

• 0.5% packet loss 

To calculate R = 94 - 1c - Id - Ip, use Table 40, Table 41, and Table 42: 

• G.711 codec: lc = 0 

• 20 msec network delay: Id = 0 

• 0.5% packet loss: Ip = 2 

Then: 

R = 94 - 0 - 0 - 2 
R = 92 

Using Table 43 on page 182, a value of 92 means the users are very satisfied. 

Scenario 2 

A campus network has the following characteristics: 

• G.711 codec 

• 50 msecs delay 

• 1.0% packet loss 

To calculate R = 94 - lc - Id - Ip, use Table 40, Table 41, and Table 42: 

• G.711 codec: lc = 0 

• 20 msec network delay: Id = 5 

• 0.5% packet loss: lp = 4 
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Then: 

R = 94 - 0 - 5 - 4 
R = 85 

Using Table 43 on page 182, a value of 85 means the users are satisfied. 

Scenario 3 

A WAN has the following characteristics: 

• G.729 codec 

• 30 msec network delay 

• 2% packet loss. 

To calculate R = 94 - lc - Id - lp, use Table 40, Table 41, and Table 42: 

• G.711 codec: lc = 11 

• 20 msec network delay: Id = 5 

• 0.5% packet loss: Ip = 8 

Then: 

R = 94 - 11 - 5 - 8 
R = 70 

Using Table 43 on page 182, a value of 70 means some users are dissatisfied. 
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DiffServ 

The Differentiated Service (DiffServ) determines the priority of the packets 
in the IP network. The value entered depends on the equipment in the data 
network. The DiffServ applies to all cards in the node and also applies to any 
Internet Telephones that register with this node. 

Individual values are configurable for the voice and control DiffServ Code 
Point (DSCP) values and can be configured to a number between 0 and 63 
inclusive using OTM 2.0. 

The values are set once for each system and apply to all packets sent by the 
Voice Gateway Media Card and the Internet Telephone. 

If DiffServ is implemented on the network, ask the network administrator for 
the default values that are used in the system. The recommended 
configuration values are: 

• voice DSCP: 46 - Expedited Forwarding (EF) 

• control DSCP: 40 - Class Selector 5 (CS5) 

Note: OTM and Element Management has 46 and 40 as the default 
values. 

Loss and Level Plan 

The Voice Gateway Media Card ships with a predefined loss and level plan. 
The loss and level plan determines various parameters, such as transmission 
gain, that vary from country to country. The default loss and level plan is for 
the United States. The values are stored in a file on the OTM PC. You can 
select other countries when you configure the DSP Profile settings in OTM’s 
ITG Line 3.0 application or the Loss Plan settings in Element Management. 

Note: A dynamic loss plan has been implemented on the Succession 
CSE 000 Rel 2.0 system. It uses PDCA Table 15 in LD 73 to define the 
gateway loss value per endpoint connection type and adjusts the Voice 
Gateway Media Card gateway channel’s loss for each call by sending pad 
values to the card. The default values in the system are for the North 
American loss plan. Installation of the Succession CSE 000 Rel 2.0 


IP Line Description, Installation, and Operation 





Page 186 of 724 IP Network Engineering Guidelines 


system in any other country requires setting the pad values in Table 15 to 
that country's loss plan. See the section on Transmission Parameters in 
Planning and Engineering Guidelines (553-3023-102) for details. 

Echo canceller 

OTM supports echo canceller tail lengths of 8, 16, and 32 msec. The default 
in OTM is the maximum of 32 msec. Element Management supports echo 
canceller tail lengths of 0,64, and 128 (default) msec. It is recommended that 
the maximum echo canceller tail length is used. Never reduce the echo 
canceller tail delay value unless directed by Nortel Networks Field Support. 

OTM's scaling process 

The IP Line loadware contains an enhanced echo canceller. The new echo 
canceller has improved echo cancellation algorithms and supports tail lengths 
up to 128 msec. OTM 1.0.15 does not offer the enhanced tail length values in 
the echo canceller tail pull down menu. Because the IP Line loadware can be 
used with any supported version of the OTM product, it scales the configured 
tail length, if necessary, so that the maximum tail length is achieved. The 
scaling provides the following echo cancelling tail lengths: 

8 -> 32 msec 
16 -> 64 msec 
32 -> 128 msec 

The maximum tail length is the recommended value. Selecting the OTM 
default of 32 msec yields the desired maximum tail length of 128 msec. 

An update to OTM changes the echo canceller tail configuration pull down 
list to the values 64 and 128. When used with the IP Line loadware, the 
application no longer needs to scale the configured value. The configured 
value matches the tail length used by the echo canceller. 

Note: If the OTM version 2.0 is used with an ITG Line 2.0 loadware 
version, such as ITG Line 2.01.53, selecting 64 or 128 msecs sets the 
echo tail length to 32 msec. 
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Reducing delays 

The link delay is the time it takes for a voice packet to be queued on the 
transmission buffer of a link until it is received at the next hop router. Link 
delay can be reduced by: 

• Upgrading link capacity. This reduces the serialization delay of the 
packet, but also reduces the utilization of the link and the queueing delay. 
Before upgrading a link, the technician must check both routers 
connected to the link to be upgraded and ensure compliance with router 
configuration guidelines. 

• Implementing a priority queueing discipline. 

To determine the links for upgrading, list all the intranet links used to support 
the IP Line traffic. This can be derived from the traceroute output for each site 
pair. Use the intranet link utilization report and note the highest used links and 
the slowest links. Estimate the link delay of suspect links using the traceroute 
results. 

Example: A 256 Kbps link from routerl to router 2 has a high utilization. The 
following is a traceroute output that traverses this link: 

II*Line Model % traceroute SubnetA 

traceroute to SubnetA (10.3.2.7), 30 hops max, 32 byte packets 

routerl (10.8.0.1) 1 ms 1 ms 1 ms 

router2 (10.18.0.2) 42 ms 44 ms 38 ms 

router3 (10.28.0.3) 78 ms 70 ms 81 ms 

router4 (10.3.0.1) 92 ms 90 ms 101 ms 

SubnetA (10.3.2.7) 94 ms 97 ms 95 ms 

The average rtt time on the example link is about 40 ms; the one-way link 
delay is about 20 ms, of which the circuit transmission and serialization delay 
are just a few milliseconds. Most of this link's delay is due to queueing. 
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Reducing hop count 

The IP Telephony nodes must be connected to the intranet to minimize the 
number of router hops between the Voice Gateway Media Card and the 
Internet Telephone. This reduces the fixed and variable IP packet delay, and 
improves the Voice over IP Quality of Service. It is recommended that no 
more than one card use a particular lOBaseT LAN collision domain. 

Note: In a passive Ethernet hub, all ports on the hub share one 10Mbps 
collision domain; in a switched Ethernet hub, each port has its own 
collision domain. Hubs should not be used anywhere in the network path 
between the internet telephone and VGMC TLAN interface. A switched 
network is recommended 

The IP Telephony node and the TLAN router should be placed as close to the 
WAN backbone as possible to: 

• Minimize the number of router hops. 

• Segregate constant bit-rate VoIP traffic from bursty LAN traffic. 

• Simplify the end-to-end QoS engineering for packet delay, jitter, and 
packet loss. 

If an access router separates the IP Telephony node from the WAN router, 
there must be a high-speed link (for example, Fast Ethernet, FDDI, SONET, 
OC-3c, ATM STS-3c) between the access router and the WAN backbone 
router. 

Reducing packet errors 

Packet errors in intranets are generally correlated with congestion somewhere 
in the network. Bottleneck links occur where the packet errors are high 
because packets get dropped when they arrive faster than the link can transmit 
them. When highly used links are upgraded, the sources of packet errors on a 
particular flow must be removed. A reduction in hop count also reduces the 
opportunities for routers and links to drop packets. 
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Other causes of packet errors, not related to queueing delay: 

• Poor link quality-the underlying circuit has transmission problems, 
high line error rates, or subject to frequent outages. The circuit is 
provisioned on top of other services, such as X.25, frame relay, or ATM. 
Check with the service provider for resolution. 

• Overloaded CPU-this is another commonly-monitored statistic 
collected by network management systems. If a router is overloaded, it 
means that the router is constantly performing processing-intensive 
tasks, which impedes the router from forwarding packets. Find out what 
the threshold CPU utilization level is, and check if any suspect router 
conforms to the threshold. The router has to be re-configured or 
upgraded. 

• Saturation-routers can also be overworked when there are too many 
high capacity and high traffic links configured on it. Ensure that routers 
are dimensioned according to vendor guidelines. 

• LAN saturation-packets are dropped on under-engineered or faulty 
LAN segments. 

• Jitter buffer too small-packets that arrive at the destination ITG, but are 
too late to be placed in the jitter buffer, are essentially loss packets. 

Adjusting jitter buffer size 

The jitter buffer parameters directly affect the end-to-end delay. Lowering the 
voice playout settings decreases one-way delay, but there is less waiting time 
for voice packets that arrive late. 

The jitter buffer setting is configured on the voice gateway channels of the 
Voice Gateway Media Card and are sent out to the Internet Telephones. The 
jitter buffer size is set when you configure the DSP Profiles: 

• in the OTM ITG Line 3.0 application (see Figure 40 on page 285), or 

• in the selected codec in Element Management (see Figure 66 on 
page 349) 
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The jitter buffer is statically configured and is the same for all devices in the 
network. The jitter buffer size range is 0-200 milliseconds. The default jitter 
buffer value is 50 milliseconds. However, the jitter buffer setting that is used 
on the Voice Gateway Media Card is a multiple of the codec frame size. The 
setting is automatically adjusted to be greater than or equal to the jitter buffer 
value set in the DSP Profile tab. As each call is set up, the jitter buffer for each 
device is set to the nearest whole number increment of the selected codec 
frame size. 

For example, if the jitter buffer is configured as the default 50 msec in the 
DSP Profiles, but a 20 msec codec is used, the jitter buffer is set to 60 msec, 
which is the nearest whole number increment. 

50 msec / 20 msec = 2.5 

2.5 rounded up to the nearest whole number increment is 3. 

3 x 20 msec = 60 msec 

If the jitter buffer is configured as zero, the depth of the jitter buffer is set to 
the smallest value the device can support. In practice, the optimum depth of 
the jitter queue is different for each call. For telephones that are on a local 
LAN connection, a short jitter queue is desirable to minimize delay. For 
telephones that are several router hops away, a longer jitter queue is required. 

Lowering the jitter buffer size decreases the one-way delay of voice packets. 
If the setting for the jitter buffer size is too small, packets are discarded 
unnecessarily. Discarded packets result in poorer speech quality and can be 
heard as clicks or choppy speech. 

If the technician decides to discard packets, to downsize the jitter buffer, the 
technician must do the following: 

• Check the delay variation statistics. 

Obtain the one-way delay distributions originating from all source IP 
Line sites. 

• Compute the standard deviation of one-way delay for every flow. 

Some traffic sources with few hop counts yield small delay variations, 
but it is the flows that produce great delay variations that should be used 
to determine whether it is acceptable to resize the jitter buffer. 
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• Compute the standard deviation (O) of one-way delay for that flow. 

Do not set the set the jitter buffer size smaller than 2s. 

Codec selection 

To ensure optimal voice quality, minimize the number of compression and 
decompression stages and wherever bandwidth permits, use G.711 codec. 

There is a potential to degrade the voice quality if codecs are cascaded. This 
can occur when there are multiple compression and decompression stages on 
a voice call. The more IP links used in a call, the more delay is added, and the 
greater the impact on the voice quality. 

The following is a list of applications and devices that can impact voice 
quality, if you use a compression codec such as G.729A: 

• Voice mail, such as Nortel Networks CallPilot, introduces another stage 
of compression and decompression. 

• Conferences can double the number of IP links. 

• ITG Trunks can add additional stages of compression and 
decompression. 

Post-installation network measurements 

The design process is continual, even after implementation of the ITG 
network and commissioning of voice services over the network. Network 
changes - in ITG traffic, general intranet traffic patterns, network policies, 
network topology, user expectations, and networking technology - can render 
a design obsolete or non-compliant with QoS objectives. The design needs to 
be reviewed periodically against prevailing network conditions and traffic 
patterns. 

It is assumed that the customer’s organization already has processes to 
monitor, analyze, and re-design both the Meridian 1 and Succession 
CSE 1000 network and the corporate intranet to maintain internal QoS 
standards. When operating an ITG network, additional processes must be 
developed to: 

• collect, analyze, and forecast ITG traffic patterns 
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• monitor Operational Measurements (see below) 

• implement changes in the ITG and intranet when planning thresholds are 
reached 

By establishing these new processes, the ITG network can be managed to 
ensure that desired QoS objectives are met. 

ITG Operational Measurement (OM) 

The Voice Gateway Media Card collects Operational Measurements from the 
Internet Telephones and DSP channels and saves the information to a log file 
every 60 minutes. The Operational Measurements include: 

• Internet Telephone Registration Attempted Count 

• Internet Telephone Registration Confirmed Count 

• Internet Telephone Unregistration Count 

• Internet Telephone Audio Stream Set Up Count 

• Internet Telephone Average Jitter (msec) 

• Internet Telephone Maximum Jitter (msec) 

• Internet Telephone Packets Lost/Late (%) 

• Internet Telephone Total Voice Time (minutes and seconds) 

• Gateway Channel Audio Stream Set Up Count 

• Gateway Channel Average Jitter (msec) 

• Gateway Channel Maximum Jitter (msec) 

• Gateway Channel Packets Lost/Late (%) 

• Gateway Channel Total Voice Time (minutes and seconds) 
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OM Report description 

The OM log file is a comma-separated (.csv) file stored on the OTM server. 
Using OTM you can run an adhoc report or schedule a regular report. A new 
file is created for each month of the year in which OM data is collected. It can 
be read directly or imported to a spreadsheet application for post-processing 
and report generation. Collect these OM reports and store them for analysis. 
At the end of each month, identify the hours with the highest packet lost/late 
statistics and standard deviation statistics generated. Compare the data to 
target network QoS objectives. 

Declines in QoS can be observed through the comparison of QoS between last 
period and current period. A consistent inferior measurement of QoS 
compared with the objective triggers an alarm. The customer must take steps 
to strengthen the performance of the route.The card creates a new log file 
each day. Files are automatically deleted after seven days. 
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IP Line ELAN and TLAN configuration 

A subnet is defined as a remote network serving a collection of Internet 

Telephones, which is represented by a server or router communicating with 

the ITG processor for VoIP service (see Figure 10 on page 169). 

General requirements 

The general requirements are as follows: 

• no foreign broadcast coming from other subnets 

• no BootP relay agent requirement (only on ELAN router interface) 

• no Network Address Translation (NAT) between Internet Telephone and 
IP Telephony node 

• the TLAN cable between the ITG-P Line Card and the Layer 2 switch 
must be 50 meters or less 

• disable spanning tree on the Layer 2 switch ports connected to the ELAN 
and TLAN ports of the Meridian I and Succession CSE 1000 
components 

Separate subnet configuration 

Each Voice Gateway Media Card has two Ethernet ports, one for the 

Telephony LAN (TLAN) and one for the Embedded LAN (ELAN). The 

advantages of this configuration are: 

• optimization of VoIP performance on the LAN segment by segregating 
it from ELAN traffic and connecting the TLAN as close as possible to 
the WAN router. 

• making the amount of traffic on the TLAN more predictable for QoS 
engineering. 

• enhanced network access security when the ELAN and customer's 
enterprise network are separate or connected through a fire-wall router: 
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— enables placement of the modem router on the isolated ELAN, 
protecting the customer's enterprise network from unauthorized 
modem router accesses 

— protects the Meridian 1/Succession CSE 1000 ELAN from 
unauthorized access from the customer's enterprise network 



CAUTION 

Due to backwards compatibility, the user interface 
permits you to choose whether to use separate subnets. 
It is, however, mandatory to use separate subnets. 


ELAN/TLAN Half and Full Duplex operation 

The ELAN on the Voice Gateway Media Card operates at Half Duplex only 
and is limited to lOBaseT operation due to filtering on the Meridian 1 
Option 11C back planes. 


The TLAN on Voice Gateway Media Card operates at Half Duplex or Full 
Duplex and can run at lOBaseT or 100BaseT. 

It is recommended that any network equipment connected to the ELAN or 
TLAN be set to Auto Sense / Auto Negotiate for correct operation. Although 
Full Duplex is preferred, it is not required. For example, for the IP Line 
application, Half Duplex has ample bandwidth for a Voice Gateway Media 
Card even with 24 busy channels, VAD disabled, and G.711 codec with 10ms 
voice range. 
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Mismatches can occur if devices are hard configured for speed and duplex 
mode. Every device and port must be correctly configured to avoid duplex 
mismatch problems that typically exhibit as lost packets and CRC errors. The 
Voice Gateway Media Card cannot be set for lOOBaseT/Full Duplex 
operation, and as a result the card’s TLAN operates in Auto Negotiate mode. 
Duplex mismatches and lost packets occur if the TLAN interface is not 
configured properly. 



CAUTION 

Duplex mismatches occur in the LAN environment 
when one side is set to Auto Negotiate and the other is 
hard configured. 


The Auto Negotiate side adapts only to the speed setting 
of the fixed side. For duplex operations, the Auto 
Negotiate side sets itself to Half Duplex mode. If the 
forced side is Full Duplex, a duplex mismatch occurs. 


Subnet configuration for TLAN and ELAN ports 

Single subnet configuration implies the configuration and use of just one 
Ethernet interface, namely the ELAN interface, over which all voice and 
management traffic is routed. Single subnet configuration can also mean 
configuring both the TLAN and ELAN interfaces to be in the same subnet. 
Neither configuration is supported. The configuration of the ELAN and 
TLAN must be done such that both interfaces are used and the assigned IP 
addresses are in different subnets. 

Separate or dual subnet configuration implies the configuration of both the 
TLAN and ELAN interfaces. All management traffic is routed over the 
ELAN, while all telephony traffic is routed over the TLAN. The ELAN 
connection is to a lOBaseT hub or switch, while the TLAN is connected to a 
10/100BaseT switch. 
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For dual subnet configuration, the TLAN and ELAN subnets must not 
overlap. For example, the following configuration is not valid, as the TLAN 
and ELAN subnets overlap. 


ELAN IP 
ELAN Gateway 
ELAN Subnet Mask 
TLAN Node IP 
TLAN Card IP 
TLAN Gateway 
TLAN Subnet Mask 


10.0.0.136 

10.0.0.129 

255.255.255.224 

10.0.0.56 

10.0.0.57 

10 . 0 . 0.1 

255.255.255.0 


The ELAN range of addresses, 10.0.0.129 to 10.0.0.160, overlaps with the 
TLAN range of addresses, 10.0.0.1 to 10.0.0.255. This fails to keep with IP 
addressing practices, as it is equally valid to route to IP packets over either 
the TLAN or ELAN interface and the resulting behavior from such a setup is 
undetermined. 

A better way to split these IP addresses is: 

ELAN IP 10.0.0.136 

ELAN Gateway 10.0.0.129 

ELAN Subnet Mask 255.255.255.224 

TLAN Node IP 10.0.0.56 

TLAN Card IP 10.0.0.57 

TLAN Gateway 10.0.0.1 

TLAN Subnet Mask 255.255.255.128 

In this example: 

• TLAN IP addresses are in the range of 10.0.0.1 to 10.0.0.127 

• ELAN IP addresses are in a separate subnet of 10.0.0129 to 10.0.0.160 

This satisfies the IP addressing practice of engineering the network such that 
subnets do not overlap. However, this results in a smaller subnet for the 
TLAN address. 
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Spanning Tree Option on Layer 2 switches 

Nortel Networks recommends disabling the spanning tree option on the 
Layer 2 switch ports that connect to the Meridian I and Succession CSE 1000 
system's TLAN and ELAN interfaces. 

This option is "enabled" by default on most Layer 2 switches. If the option is 
left enabled, the subsequent spanning tree discovery algorithm initiated when 
a device connected to a port is reset, rebooted, or unplugged/plugged-in, can 
interfere with the Master Election Process of the Meridian I and Succession 
CSE 1000 system devices. In most cases the Master Election Process 
recovers from this after a slight delay. However, to reduce the potential of 
unforeseen complications in this scenario it is recommended that the 
spanning tree option on these ports be disabled. 

LAN Device Interface Names 

The devices in the system have different Device Interface Names depending 
on whether is it is on the TLAN or on the ELAN. Table 44 on page 198 shows 
the Device Interface Name for the Succession Media Card, ITG-P Line Card, 
and the Signaling Server. 


Table 44 

LAN Device Interface Names 


Device Type 

TLAN/ELAN 

LAN Device 

Interface Name 

Succession Media 

Card 

ELAN 

ixpMad 

TLAN 

ixpMacO 

ITG-P Line Card 

ELAN 

InlsaO 

TLAN 

InPcil 

Signaling Server 

ELAN 

feiO 

TLAN 

feil 
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